백만년전에 KELP 에 썼던 글. 의외로 이 글에서 레퍼러가 많이 달려서...
부트로더에서 자신을 sdram으로 복사하는 이유는?
-> 일반적인 정답 : NOR 로서 코드가 실행 중일때 NOR에 스스로는 써넣기가 불가능하므로.
그 외 간과하기 쉬운 중요한 사실. (추가 덧글의 부탁 이후에 뷰는 많은데 리플이 없음)
그렇다면...
이런 문제에 있어서 속도는 굉장히 중요한 요인이 될 수 있습니다. 왜냐면 MMU 설정으로 인터럽트 핸들러를 몽창 다 램에다가 재구성해 놓는 중형 OS (이를테면 리눅스등등) 라면 관계없으나.
XIP를 구현하면서 인터럽트 벡터를 재구성하지 않는다든가 MMU 설정없이 사용하는 소형OS에서는 전적으로 부트로더에서 만들어놓은 인터럽트 벡터와 유기적으로 연결되어 사용될 가능성이 크다고 봅니다.
ARM 이라고 한다면 NOR의 초반 바이트들이 바로 핸들러 주소가 되겠죠. 이렇게 되면 SDRAM에 비해서 인터럽트 처리가 많이 느려지겠지용.
워스트케이스를 들어봅시다.
초경량 RTOS-이더넷 수신다량이라고 하면 이더넷에서 RX가 걸릴때마다 NOR의 IRQ 핸들러에서 부터 이더넷 처리 루틴으로 분기하게 됩니다.
만약 MMU로 그 주소를 재구성해서 인터럽트 핸들러 0번지-4*n 번지의 위치가 SDRAM으로 이동해있다면 조금은 더 고속으로 동작하겠지요.
XIP 쪽은 제가 제대로 해 본적이 없으나 이쪽도 살펴보자면 XIP는 용량절감외에 주로 FAST BOOT를 위해서 사용되므로 0.01초까지 다 쥐어짜다보면 MMU껐다 켰다 캐쉬 플러슁같은거 하면서 인터럽트 핸들러는 SDRAM으로 옮기는 일은 보통 귀찮아서 안하기도 합니다.
이런 경우도 해당사항이 될 수 있겠지요.
dawnsea (2005년 07월 25일 오후 03:17)
그러나저러나 해도. 속도 문제 외에 제가 실제로 부딪힌 이유는 NOR 에서 코드가 동작중일때는 NOR에 Writing 을 할 수 없다는 이유가 가장 컸습니다. 영역 분할을 잘 하든 하면 되지 않느냐? 라는 생각을 해 볼 수 있으나.
NOR는 구조상 커맨드에 따라서 STATUS 읽기 모드로 바뀌거나 하면서 엉뚱한 값을 보내오게 되는 플로우가 있거든요.
익명님이 올린 이유와 같았습니다 ㅡ.ㅡ;;
그리고 BSS부분 따로 부트로더 말미에 복사하는 코드를 넣는 것보다 TOP-BOTTOM 으로 나누어짠 후 BOTTOM 에서는 앗싸리 몽창 새로운 마음으로 코드를 시작하면서 가족같이 편안한 우리의 씨언어로 산뜻하게 시작하는 것이 좋겠지요.